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Method and Apparatus for Selective Data Reception 



Field of the invention 

The invention relates to the selective reception of data from a broadcast service, 
i The invention is particularly suitable for» but not limited to, IF data broadcasting 
over unidirectional networks. 



Background of the invention 

An Internet protocol (IP) service can include plural items delivered using an IP 
10 session. An IP session may include an IP stream carrying primary content, such as 
live or recorded music, and further IP streams carrying secondary content^ such as 
error correction or song lyrics. Such services can be broadcast in a multiplexed 
transport stream using terrestrial digital video broadcast, fox example DVB-T, 
ISDB-T or ATSC-T, or DVB-S (satellite), DVB-C <cable) or Digital Audio 
fS Broadcasting (DAB) networks. 

Wireless IP networks typically serve one or more mobile terminals having stringent 
power requirements. Such a terminal may be required to operate for lengthy 
periods on an internal source of power. In the case of simplex broadcast systems 
20 supporting unidirectional dau delivery, for example DVB-T or DVB-S networks, a 
large proportion of the power consumption in a terminal is due to the demands of a 
receiver when receiving data transmissions. It is desirable to conserve power by 
reducing the amount of data received, i.e. by receiving only selected data. 

2S Selective data reception can be implemented for receiving a particular stream of data 
in a Time Division Multiple Access (TDMA) transmission by switching the receiver 
between its on and off states, so that data reception is suspended during time slots 
relating to services or content that are not required. In our co-pending application, 
G6021 6240.2, a method is disclosed in which a session announcement is 

JO transmitted on a first channel in a transport stream. If a service is of interest to a 
user of die terminal, the information conveyed in the service announcement can be 
used to control the operation of the receiver in order to selectively receive 
broadcast or multicast data relating to that service. This information may include 
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the frequency of the broadcast channel carrying a particubr service, a description of 
the service in terms of a category, e.g. news, sport, entertainment, and a sub- 
category, for example, the sports category may be divided into football, hockey, 
athletics sub*categories. The information may also include the number of messages 
/ containing the relevant content that will be sent and a time out value. When data 
reception is not required, i.e. when data relating to the selected service is not being 
transmitted, the receiver is disabled, in order to conserve power. 

In another co-pending application, PCT/IB02/04823, a receiver is conttoUed to 
W selectively receive data using a schedule of delivery time slots, where the schedule is 
extracted from information relating to the IP address of the content source 
provided in a session announcement. The receiver may be switched off or operated 
at a lower power between the delivery time slots, when data reception is not 
required. 

IS 

The performance of these methods may be improved by grouping related data 
packets into bursts before their transmission. The transmission takes the form of a 
sequence of btirsts uking up most or all of the available bandwidth for a relatively 
short period of time, each burst carrying a significant amoimt of interrelated data. 

20 Information relating to the burst duration and the interval between related bursts is 
encoded into the headers of the data packets in the bursts, while information 
describing the contents of the burst are signalled using external address mapping 
functionahty provided by the transmission network baseline, such as the network 
information table (NIT) table in a DVB system. This further reduces the period of 

2S time for which the receiver is actively receiving data. 

Summary of the invention 

According to the invention, a terminal for selectively receiving broadcast data in a 
data stream, wherein the broadcast data includes a series of biirsts of dau packets, 
30 comprises a receiver and a controller, wherein the controller is configured to extract 
information identifying a group of data packets in a first burst, calculate a burst 
length and burst interval for the series of bursts on the basis of instances of time at 
which bursts of data packets belonging to said group arc received by the receiver. 
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determioc a further instance of time at which a subsequent burst corresponding to 
the extracted information in the series of bursts is expected to be received based on 
at least one of said burst length and burst interval and operate the receiver to 
receive the subsequent burst corresponding to the extracted information by 
5 selectively receiving the datai stream. 

As the burst length and burst interval are derived by the controller using the 
reception times of data bxirsts, the need to broadcast this information explicitly, for 
example in the data packet headers or in an external table» is removed. Therefore, 
10 in comparison to prior arrangements, a reduced amount of data is transmitted and 
received. The available bandwidth is used more efficiently and the power 
consumption of the receiver is reduced. 

Address information relating to a source of the data may be included within the 
15 bursts or, alternatively, extracted from a session axmouncement. 

Selective reception of the data bursts may be effected by switching the receiver 
between two operation modes. Preferably, these operation modes are on and off 
states, so that the receiver power consumption is minimised. 

20 

The extraction of information identifying a group of data packets and the 
calculation of the burst length and the burst interval are preferably performed for 
each series of associated data bursts in all data streams received by the terminal 
when the terminal is switched on. However, this procedure may be performed in 
25 response to a request for reception of a particular service from a user of the 
terminal. 

The exuaction of identifying information from the data packets and the calculation 
of the burst interval and the burst length may also be repeated at regular intervals 
30 and/or in response to notification that a configuration of the data stream has 
changed. 



1 
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The invention further provides a system for broadcasting data comprising a 
multiplexer, a transmitter and one or more of said terminals. 

A method of operating a receiver to selectively receive broadcast dau in a data 
S stream according to the invention, wherein the broadcast data includes a series of 
bursts of data packets, comprises extracting information identifying a group of daU 
packets in a first burst, calculating a burst length and burst interval for the series of 
bursts on the basis of the instances of time at which data packets belonging to said 
group arc received by the receiver, determining a further instance of time at which a 
10 subsequent burst corresponding to the extracted information in the series is 

expected to be received and operating the receiver to receive the subsequent burst 
corresponding to the extracted information by selectively receiving the data stream. 

Brief description of the drawings 

15 Embodiments of the invention will now be described with reference to the 
accompanying drawings, in which: 

Figure 1 depicts a conmiunication system according to an embodiment of the 
invention; 

Figme 2 shows the structure of a transport stream data packet header; 
20 Figure 3 is a block diagram of a terminal for use in the conmiunication system of 
Figure 1; 

Figure 4 depicts the transmission of two sets of data bursts in a transport stream; 
Figiue 5 is a flowchart showing the operation of a receiver according to. the first 
embodiment of the invention; 
25 Figure 6 shows the structure of a data burst for reception by a receiver according to 
a second embodiment of the invention; 

Figure 7 is a flowchart showing the operation of a receiver according to a third 
embodiment of the invention. 



30 Detailed description 

Figure 1 shows a broadband digital broadcast head-end 1 connected to a variety of 
sources 2, 3, 4 of content, so that data packets relating to services and/or content, 
e.g. audio-visual content, data files, images, ate delivered to the head-end 1. In this 
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example, these data packets arc in the form of IPv4 or IPv6 datagrams. The data 
packets arc encapsulated by a data processor 5 at the head-end 1 and grouped 
together into one or more bursts, which have a bandwidth equal to or approaching 
the maximum bandwidth available to the ttansport stream, and a relatively short 
S duration. A set of data packets relating to a particular service or the same content 
are arranged in the same burst or series of bursts, although a single burst may 
contain a plurality of sets of data packets that are unrelated to each other to ensure 
efficient use of bandwidth. The bursts are multiplexed by a muldplexer 6 according 
to a TDMA scheme and uansmitted in a transport stream 7 over a DVB network. 

10 

In this example, the transport stream 7 is an MP£G-2 transport stream. The 
structure of a transport stream data packet 8 is described in "AKSuide to MPEG 
Fundamentals and Protocol Analysis (Including DVB and ATSC)", Tcxtronix, Inc., 
USA 1997, and is shown in Figure 2. The data packet 8 is divided into a header 9 
fS and payload 10. The header 9 includes a packet idendfier (PID) 11, used to 

distinguish between different groups of packets, and a continuity counter 12, which 
is incremented each time a new packet having the same PBD 11 is transmitted so 
that the received data packets can be assembled in the correct otder at their 
destination. 

20 

The transport stream 7 is broadcast to one or more terminals 13. In the case of a 
satellite network, the transport stream 7 may be broadcast to terminals falling under 
the satellite footprint. In a terrestrial system, the transport stream 7 is broadcast to 
terminals 1 3 that are located within areas of coverage of one or more network 
2S transmitters 14. Each terminal 13 is under the control of a user who is able to 

select a particular service or content from those transmitted in the transport stream 
7- 

A suitable terminal 13, which, in this example is a mobile handheld 
30 telecommunications device, is shown in detail in Figure 3 and comprises an internal 
power supply io the form of a rechargeable battery 15, a conuoUer 16, with an 
associated clock 17, a user interface 18» a receiver 19, a cellular uansceiver 20, 
codecs 21, 22, memory 23 and a data storage facility 24, such as RAM and/orHOM 
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memory. The receiver 19 is configured to receive the transport stream 7 broadcast 
over the DVB network while the cellular uansceivcr 20 enables mobile telephone 
communication via a cellular network. The receiver 19 has a relatively large powet 
requirement when compared with other components of the terminal 13. In order to 
5 minimise drain on the battery 15, the receiver 19 can be switched on and off in 
response to instructions received from the controller 16. 

When the terminal 13 is first switched on, the controller 16 begins compiling a 
mapping table comprising information such as a Packet Identifier (PID), burst 
length and burst interval associated with various services transmitted in one or more 
transport streams 7. In conventional devices* this information would be provided 
either in the headers of the encapsulated data packets or in a session announcement 
received separately from the transport stream 7. However, in accordance with the 
invention, this information is derived by the terminal 13, having been conveyed 
implicitly by the transport stream 7. 

A procedure for deriving this information will now be described with reference to 
Figure 4 and Table 1. Figure 4 depicts an exemplary transport stream 7 comprising 
two sets of bursts, with PIDs Bl, B2, comprising data packets associated with first 
20 and second services respectively. Table 1 shows the information held in the 
mapping uble maintained by the controller 1 6 during the procedure. In this 
example, as the mapping table is being compiled in response to the terminal 13 
being switched on, it is presumed that a user of the termirul 13 has not yet 
instructed the terminal to receive either of the first and second services. 

25 
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Table 1 

The receivci 19 is tuned to the baseband of the transport stream 7 at time t,. A first 
burst of data packets with a first PID Bl is received, beginning at time tj. As there 
S is no information in the mapping table relating to PID Bl, the receiver 19 remains 
switched on. At time t,, the PID of the data packets in the transport stream 7 
changes from Bl to another PID (not shown). The receiver 19 detects the change 
in the PID of the received data and the conttoUer 16 stores a value for the burst 
length of: 

10 ^» 

as part of an entry in the mapping table relating to PID Bl. 

» 

The start of the burst may be detected from a field in the header 9, as shown in 
IS Figure 2, such as the PID field 1 1 or the adaptation field 22, or from a field in the 
payload 10, such as a Media Access Conuol (MAC) field, not shown, or by using a 
combination of fields in the header 9 and/or in the payload 10. Where the payload 
10 comprises dau packets with one or more dau packet headers and payloads, the 
start of the burst may be detected using one or more fields or a combination of 
20 them from these headers or payloads. 

The conuoUer 16 may have access to information regarding the time delay betwcca 
the 'real' start time of the burst, i.e. the time at which reception of the burst begins 
at the terminal 13, and the instant of time when the detection of a particular field, 

2S e.g. PID field 11, takes place. This information may be used to correct the start time 
tj of the burst. Furthermore, the start time tj may be corrected to take into account 
possible jitter by inuoducbg a suitable correction term. This correction term may 
be of the order of 1 to 5 ms. The jitter correction term may be predetermined or it 
may be determined by the controller 1 6 based on received date, In a similar way, 

30 the end time of the biust t3 may be corrected to take jitter into account by 
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inaoducing a second correction term of substantially the same size as. the fitter 
coriecdon term and obtained in a similar way. 

As the user has not instructed the terminal to receive the first service, when the first 
5 of the next burst of data packets with PID Bl is received at time the receiver 19 
is switched off for a first time period of t^, in order to conserve battery power. At 
this point, a value of: 

tH= (t4-ta), 

10 fpr the interval between bursts for PID Bl is stored in the mapping toblc. 

Alternatively, the interval may be defined as the time from the end of the burst to 
the end of the next burst with the same PID, for example, as: 



IS 



When time period t^i expires at time t,, the receiver 19 is switched on again and 
continues receiving dau. 

20 

In this example, a burst of data packets with a PID B2 is received at a time t^. The 
receiver 19 detects that the PID has changed and, as there is no information relating 
to PID B2 in the mapping table, remains switched on. When the PID changes at 
time t7, a value for burst length of: 

is stored in the mapping table in an entry relating to PID B2 and the receiver 19 
continues receiving the transport stream 7, The start time t* of the burst with the 
PID B2 may be corrected for jitter as explained above in relation to start time tj. 

30 

As the mapping table now holds the burst length and burst interval for PID Bl, the 
controller 16 will use this ioformation to switch off the receiver 19 during 
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subsequent bursts with this PID. so that no data is received during time periods t, to 
t9 and t,oto t||. 

As the user has not requested the second service, when the first of the dau packets 
S in a second burst with PID B2 is received at t^^, the controUer 16 ensures that the 
receiver 19 is switched off for a time period of length t^,. ending at time t,,, and 
stores a burst interval value: 

10 in the mapping table for use in receiving subsequent bursts with PiD B2. 

As this procedure continues, a mapping table is compiled containing the 
information necessary for the controller 16 to maintain and suspend reception of 
the transport sueam 7. The reception of unwanted dau is minimised, thereby 
/J reducing the power consumption of the receiver 19. A separate mapping table is 
compiled for each transport stream 7 received by the tertninal 13. 

In the above example, the mapping table is compiled in response to the mobile 
terminal 13 being switched on by a user. However, a terminal 13 may instead be 
20 configured so that a mapping toble is compiled in response to an instruction from 
the user for the terminal 13 to receive a service. Such an instruction may result in 
the terminal 13 sending a request for the service to a relevant service provider. 
However, in the following example, no such request is sent and the instruction to 
receive the service is acted on locally, i.e. by the terminal 13 only. 

If the user instructs the terminal 13 to receive the second service, the mapping table 
is compiled as described above, with the exception that the controller 16-ensures 
that the receiver 19 is switched on at the appropriate times for receiving data 
packets with PID B2. At time t,„ the controller 16 calculates the start time t, of the 
30 next data burst associated with PID B2 using the derived burst length tj, and burst 
interval t,j, and ensures that the receiver 19 is switched on at time t, =t,2+ t,afor a 
period equal to the burst length t^,. The controUer 16 then repeats this process. 



wo 2005/002097 



10 



PCT/1B2004/051030 



calculating subsequent start dmcs t,„=t,j+ n t,j (nS2) and operating the receiver 19 
accordingly, in order to receive subsequent bursts of data packets with PID B2. 



In either of the examples discussed above, the derivation of the burst interval and 
5 burst lengths may be repeated in order to reduce errors caused by lost data packets. 
The compiladon of the mapping table may also be repeated at regular intervals in 
order to allow for changes in the conGguration of the transport stream 7. 

The transport sUeam 7 may further include update notifications using dau packets 
10 with a specified PID 1 1 that are scheduled wiA a constant interval and length. The 
update notifications are used to indicate whether the configuration of the transport 
stream 7 is changed. Where a change has been made, the controller 16 may respond 
to the reception of the update notification by recompiling the mapping table. 

IS Where the xnapping uble is compiled in response to the terminal 13 being switched 
on, an instruction from a user to receive a particular service is handled as follows. 
With reference to Figure 5 and starting at step sO, on reception of an instruction 
(step si), the controller 16 obtains an IP address associated with an originating 
. source of that service or an address mapping along with the PID and information 

20 identifying the relevant uansport stream 7 (step 62), An address mask may be used 
instead of a single unique IP address, in particular where the burst comprises data 
packets associated with multiple IP addresses. For example, an address mask 
224.1.1.0/8 can be used to indicate 256 addresses in the range 224.1.1.0 to 
224.1.1.255. For example, this information could be extracted firom a session 

2S announcement message transmitted to the ternoinal 13. 

The controller 16 then accesses its mapping tables and determines whether they 
contain an entry corresponding to that service (step sS). If so, the controller 16 
reads the entry associated with that service from its mapping tables in order to 
30 exuact the burst length and interval (step s4). A start time t^ for the next burst is 
calculated (step sS), based on the current time, burst length and interval. The 
receiver 1 9 is then tuned to the appropriate transport stream 7 at time tj (step s6) 
and bursts of data packets with the relevant PID arc received and axe filtered using 
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the relevant address or address mapping. The conttoUcr 16 uses the burst length 
and interval to suspend reception by switching off the receiver 19 to avoid receiving 
and processing unwanted data packets. 

S If uansmission of the content or service has not been completed /step s7), the 
process is repeated by calculating the start time t^ of the next burst and tuning the 
receiver 19 to the transport stream 7 at the appropriate time (steps s5, s6). When 
the transmission has been completed, the PID of data packets received at the next 
calculated start time tj will not match that given in the mapping table. The change 

10 in PID will indicate completion of the transmission of the required content (step $7) 
and the receiver 19 is switched off. 

If the mapping ubles do not contain a corresponding entry, an error may be 
reported to the user via the user interface 1 8 (step s8). Alternatively, the mapping 
IS table compilation process described above may be repeated in order to derive the 
burst length and burst interval data associated with the requested service. 

The process is then complete (step s9). 

20 In a second embodiment of the invention, address information is provided within 
the dau packets of transport stream 7, removing the need for an external source of 
address information. With reference to Figure 6, a burst of data packets with PID 
Bl comprises two portions. The data packets of the first portion BIH contain the 
address mappings of the source IP addresses of the data packets in the second 

2S portion BIB, so that the receiver 19 can dtcz the received data packets to extract 
the requested service. 

Again referring to Figure 4, in this embodiment, the procedure for compiling the 
mapping table is similar to that described above, differing in that the source IP 
M> addresses, address masks or address mappings are also stored in the mapping table. 
The addresses are obuined by the controller 16 when the first data burst with a 
given PID is received. Table 2 shows the information stored in the mapping uble 
at various stages in the transmission as shown in Figure 4. 
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In this embodiment, the tenninal 1 3 responds to an instruction to receive for a 
particular service as follows. With reference to Figure 7 and starting at step slO, on 
reception of an instruction (step sll), the conuoUer 16 accesses its mapping ubles 
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Table 2 

and determines whether they contain an entry corresponding to that service (step 
si 2). If so, the controller 16 reads the address or address mapping, burst length and 

10 interval from that entry (step si 3). A start time % for receiving the data is then 
calculated (step si 4), based on the ciorrent time, burst length and interval. The 
receiver 19 is then tuned to the appropriate transport stream 7 at time t^ (step slS) 
and a burst of dau packets with the relevant PID is received and filtered using the 
relevant address or address mapping. The controUer 16 uses the burst length and 

IS interval to suspend reception by switching off the receiver 19 to avoid receiving and 
processing unwanted data packets. 

If the data transmission has not yet been completed (step sl6), the start time t^ for 
the next burst is calculated and receiver 19 is mned to the transport stream 7 to 
20 selectively receive the next burst (steps sl4, slS). When the data transmission has 
been completed (step si 6), as indicated by the change in PID 11 of the received 
data packets, the receiver 19 is switched off. 
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If the mapping tables do not contain a coiiesponding entry, an enor may be 
lepotted to the usex via the user interface 18 (step si 5).. 

The pxocess is then complete (step si 6). 

The embodiments described above are examples showing how the invention may be 
implemented. For example, instead of being switched between on and off stotes, 
selective data reception may be implemented by switching the receiver between high 
and low power operating modes. 

The invention is not limited to mobile terminals 13 and other forms of receiving 
device may be suitable for implementing the inventior». 

With the example given, the receiver may be any one with DVB, ISDB or ATSC 
IS baseband capability, such as a suitably equipped laptop computer. Where a network 
other than DVB-T is used, the receiver may uke any suiuble form, such as a 
personal digital assistant (PDA) or a portable sound reproduction device, such as a 
personal stereo. Alternatively, the receiver could be a wireless local area network 
(WLAN) module. 

20 
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